- 综合排序
- 最热优先
- 最新优先
- 来自专栏Visual Codex
H.266 现状
H.266，即VVC，已于2020年6月完成标准化工作，其标准号为Rec. ITU-T H.266 and ISO/IEC 23090-3，标准将在2020年11月正式开始生效。 H.266最显著的特点就是其相比起它前一代的标准，即ITU-T and ISO/IEC High Efficiency Video Coding (HEVC)，标准号Rec.
1.6K30发布于 2021-06-17 - 来自专栏RTSP/RTMP直播相关
H.266 与 AVS3 对比解析：实时视频SDK的挑战与未来
一、H.266 与 AVS3 的核心差异虽然 H.266 与 AVS3 都被称作「新一代超高清编解码标准」，但二者在起源、目标和应用环境上存在显著差异。 协议层对接 —— RTSP/RTMP/GB28181/WebRTC 等传输协议需要支持新的 SDP 描述与封装方式，确保拉流、推流的兼容性。 4. 协议层适配：扩展 RTSP/RTMP/GB28181/WebRTC 的 SDP/信令能力，支持 H.266/AVS3 的描述和封装。 应用链路：医疗/教育采集端 → 编码（H.265/H.266/AVS3） → RTSP/RTMP → SDK 播放/互动。 应用链路：无人机/摄像头推流 → RTSP/RTMP → 大牛直播SDK 播放器 → AI 分析/控制端。
65310编辑于 2025-08-20 - 来自专栏RTMP推送
超高清与低延迟并行：H.266 在行业视频中的落地图谱
三、大牛直播SDK的支持路径 作为跨平台、低延迟、模块化的实时视频基座，大牛直播SDK已经在 H.264/H.265 编解码和链路优化上形成了成熟的产品矩阵： 推流端：RTMP 推流 SDK 支持 H 播放端：RTSP/RTMP 播放器在多平台实现 100–200ms 的低延迟解码和渲染，适配安防、教育、工业、低空经济等行业。 路径：待硬件厂商逐步开放 GPU/ASIC/移动端芯片的 H.266 硬件加速能力后，SDK 将提供 RTMP/RTSP 推流端的编码支持。 路径：在边缘节点和云端增加 H.266 转码模块，支持 H.264/H.265 ↔ H.266 的互转。 四、H.266 × 大牛直播SDK 的行业落地场景 H.266 的价值，只有在行业场景中结合 SDK 才能被真正释放。
75810编辑于 2025-08-20 - 来自专栏RTMP推送
H.266 vs H.265AV1H.264：从工程落地看下一代视频系统的技术演进
作为多年专注于RTSP/RTMP 实时流媒体链路、低延迟直播系统的技术实践者，我们尝试从编解码效率、实时传输适配性、硬件生态、系统落地等多个维度，全面梳理 H.266、H.265、AV1 及 H.264 阶段，缺乏高效实时实现； 推拉流直播系统（如 RTMP / SRT / RTSP）对延迟极度敏感，编码端延迟常成为系统瓶颈。 工程建议： 当前可采用 H.265 编码 → 云端离线转码为 H.266 存档的方式；待芯片侧支持 H.266 后，再实现原生边缘编码与分发。 大牛直播SDK的RTSP和RTMP播放器延迟展示：1️⃣ 技术演进节奏：从离线转码到实时分发的路线图阶段当前进展典型标志标准发布期✅ VVC 标准定稿，参考实现公开Fraunhofer VVenC/VVdeC 2️⃣ 谁会最先用上 H.266？
1.6K20编辑于 2025-08-01 - 来自专栏关键帧Keyframe
音视频基础概念合集：148 个问题带你快速上车音视频丨音视频基础
参见：《视频编码（3）》第 3.1.4 节 H.266 在熵编码上有什么改进？ 参见：《视频编码（3）》第 3.1.5 节 H.266 在环路滤波上有什么改进？ 参见：《RTMP 协议》第 1 节 为什么直播推流首选 RTMP 协议？ 协议设计对低延时、音视频同步等能力有良好的支持。 参见：《RTMP 协议》第 1 节 RTMP 设计的目标是解决什么问题？ 参见：《RTMP 协议》第 1 节 什么是 RTMP 中的消息和块？ 消息，服务于数据封装，是 RTMP 协议中的基本数据单元；块，服务于网络传输，是对消息的分片。 参见：《RTMP 协议》第 1.2 节 RTMP 的核心设计思想是什么？ 分包、多路复用、消息层的优先级划分、块大小协商、压缩优化。
1.7K21编辑于 2022-06-13 - 来自专栏TSINGSEE青犀视频
为什么H.266未能普及应用？
然而，尽管H.266拥有诸多技术优势，但至今仍未能在市场上广泛流行，这背后有多重原因。一、为什么H.266尚未广泛流行1）技术门槛与配套解决方案首先，H.266技术的实现需要相应的配套解决方案。 虽然已有企业开始设计支持H.266的芯片和软件，但这些产品还未大规模应用，导致技术门槛较高，限制了H.266的普及速度。H.266要成为主流，必须得到广泛的硬件和软件支持，这需要时间来逐步实现。 H.266不是免费的开源解码器，目前存在着专利问题未解决，高昂的专利授权费用让许多生产硬件设备的厂商难以承担。这种不确定性使得许多企业在选择视频编码标准时持谨慎态度，从而影响了H.266的普及。 因此，在H.265尚未完全普及的情况下，H.266要想在市场上占据一席之地，需要克服更多的市场阻力和竞争压力。4）技术成熟度与应用场景此外，H.266的技术成熟度也是影响其普及的一个因素。 因此，尽管H.266在理论上具有显著优势，但在实际应用中，特别是在早期阶段，其应用场景可能相对有限。随着技术的不断发展和市场的逐步成熟，H.266的应用场景有望逐渐扩大。
68110编辑于 2024-09-12 - 来自专栏RTMP推送
8K、AI、低空智联，H.266能否撑起下一代视频通路？
，将 RTSP(H.266) 转换为 RTMP等更兼容格式； 多级缓存与调度：结合多路流的 QoS 调控策略，优化大规模接入设备下的链路稳定性与延迟控制。 目标不是立即替代，而是打造支持 H.266 的“演进型视频链路”，适应未来 AI 视频需求的逐步转型。 四、 实践场景：为什么 H.266 值得期待，但不能急于上线？ 适合“边缘智能 + 高压缩”的场景：H.266 的价值被最大释放场景类型应用案例为什么适合 H.266？ ) → RTMP/HLS(H.265) 的桥接链路大牛直播SDK支持协议桥接与解码卸载 全面普及后随终端支持度提升，将主链路升级为原生 H.266播放器/推流器层解耦架构保持升级能力✅ 小结：有潜力，不等于立刻可用 H.266 值得期待，但更值得“用对场景、选好时机”。
49400编辑于 2025-07-31 - 来自专栏音视频咖
腾讯云直播全线支持新一代视频编码标准H.266
腾讯云直播全线支持H.266 云端支持H.266，主要包括两部分：H.266的传输分发和H.266编解码的支持。 业界上行推流和低延时的场景，普遍采用RTMP协议或者HTTP传输FLV的方式；其都使用了FLV容器格式。但FLV标准已停止更新，目前缺少H.266编码格式支持。 FLV封装H.264的方式参考了MP4标准，H.264、H.265和H.266的比特流格式具有相似性，我们可以参照FLV封装H.264的方式以及MP4封装H.266的方式，来实现H.266 in FLV （腾讯云媒体处理MPS在2021 已率先在业界支持了H.266的点播功能） H.266视频编码 腾讯自研的H.266编码器O266，作为行业领先的VVC编码器，相比开源H.266编码器vvenc，在相同压缩速度下 H.266/VVC视频解码 在2020年H.266/VVC最终定稿后的三个月内，腾讯在国内率先开源发布了实时 H.266/VVC播放器O266player，内置腾讯自研的H.266/VVC解码器O266dec
3K30编辑于 2023-02-27 - 来自专栏用户1692782的专栏
手撕Rtmp协议细节（3）——Rtmp Body
上一篇讲了RTMP数据包中关于Header的数据组织格式，不过一个完整的RTMP数据包除了Header之外，紧跟着的是RTMP Body，这一篇就继续来说一下RTMP Body的数据组织结构了。 说到RTMP Body的数据包组织格式，就不得不提到AMF。 那么AMF和RTMP Body又有什么关系呢，不才，RTMP数据包的序列化就是按照AMF的格式进行的。 说完AMF，再回到我们的RTMP Body，RTMP Body就是按照AMF0规范，将数据包进行组织，然后再通过网络发送的。 好了，接下来就结合wireshark实际抓到的RTMP数据包，一起熟悉AMF0，同时也熟悉RTMP Body的数据包组织方式。 先看一下_result的数据包。 ?
3.3K40发布于 2020-05-20 - 来自专栏用户1692782的专栏
手撕rtmp协议细节（2）——rtmp Header
rtmp的协议的数据包，总的来讲分为两大部分，一部分是Rtmp Header，另一部分为Rtmp Body，这一篇我们来主要讲解一下Rtmp Header的组织形式。 RTMP header的长度不固定，可能的长度为12字节，8字节，4字节，1字节。具体长度为多少个字节，由RTMP header数据包的第一个字节的高2位决定。 ? 抓包看下，RTMP HEADER的长度。 图中，RTMP Header的第一个字节为0x03，高两位的值为00，所以，整个RTMP Header的长度就是4个字节了。 知道了RTMP header的第一个字节的作用以后，接下来我们看下几种不同长度的RTMP Header。 12字节的RTMP Header ?
4.5K40发布于 2020-05-20 - 来自专栏RTSP/RTMP直播相关
多路RTSP-RTMP转RTMP定制版
大牛直播SDK(Github)多路RTMP/RTSP转RTMP转发软件，系原有转发SDK基础上，官方推出的Windows平台定制版。 如监控类摄像机、NVR等，通过厂商说明或Onvif工具，获取拉流的RTSP地址，图形化配置，完成拉流转发等操作，轻松实现标准RTMP服务器（或CDN）对接。 视频转发支持H.264、H.265（需要RTMP服务器或CDN支持扩展H.265），音频支持配置PCMA/PCMU转AAC后转发，并支持只转发/录制视频或音频，RTSP拉流端支持鉴权和TCP/UDP模式设置和 添加转发项配置信息 [image] 配置说明： 添加配置项：点击页面“添加”按钮： ² 序号：无需关注，系统自动生成； ² 名称：该路转发配置项的描述信息； ² 拉流地址（必须填）：需要转发的RTSP或RTMP 地址； ² 推流RTMP地址：需要转推的RTMP地址； ² 推流播放地址：需要预览的播放地址； ² 音视频转发选项：可选择之转发音频或视频，亦或同时转发音视频； ² 录像参数配置：可选择录制音频或视频，
3.2K30发布于 2019-09-11 - 来自专栏RTMP推送
SmartMediakit视角构建低空经济的超低延迟视频基础设施
大牛直播SDK凭借全自研跨平台内核，构建了从采集、推流、传输到播放、转发的完整能力，涵盖 RTSP/RTMP 推流、超低延迟播放器、轻量级 RTSP 服务、GB28181 对接、多路转发等核心模块。 多协议与跨平台兼容： 行业内常见的 RTSP、RTMP、GB28181 等协议各有优劣，设备和平台环境高度异构，意味着底层实现必须足够灵活，否则就会陷入“碎片化适配”的困境。 跨平台一致性：支持 Windows、Linux（x86_64/aarch64）、Android、iOS、Unity，全链路保持统一体验； 可扩展与演进：已验证 H.265/HEVC 支持，并为 H.266 / Linux (x86_64/aarch64) / Android / iOS / Unity 全覆盖工程复杂度代码复杂，难以维护，调优成本高模块化封装，接口清晰，快速集成未来演进对 H.265/H.266 /AV1 的支持依赖社区进度已支持 H.265/Enhanced RTMP HEVC，预留 H.266/AV1 扩展接口可以看到，开源方案更多适合科研、验证或轻量级应用，而在低延迟、稳定性、跨平台、合规对接都要求极高的低空经济落地场景中
30500编辑于 2025-08-27 - 来自专栏全栈程序员必看
rtmp协议详解_rtmp服务器
前言 最近在学习rtmp协议，在看官方文档的时候总是懵懵懂懂，硬生生看了两天，现在基本上了解rtmp协议了，想用自己觉得比较清晰的方式来讲解rtmp协议，希望能够对向我一样的初学者有所帮助。 本文将通过以下四部分讲解rtmp协议。 1、消息 2、块 3、rtmp的消息类型 4、实例分析rtmp传输过程 一、消息 消息是rtmp的基本数据单元，服务端和客户端通过在网络上发送RTMP消息进行通讯。 消息格式 RTMP消息头和载荷两部分。 上面已经详解讲解了rtmp的数据格式了，下面来讲解具体的rtmp协议内容。 载荷 块的载荷就是消息的载荷内容。 总结一下：消息是rtmp的基本数据单元，块是用于将消息重新封装在网络上传输。
3.6K12编辑于 2022-11-01 - 来自专栏RTSP/RTMP直播相关
如何在RTMP推送端和RTMP播放端支持Enhanced RTMP H.265(HEVC)
遗憾的是，尽管CodecID可以自定义，但CodecID只有4个bits，增加H.265尚可，如果后续再新增VP8、VP9、 AV1甚至H.266就很尴尬，这种尴尬持续了数年，直到官方发布了 Enhancing RTMP新的规范。 技术实现本文以大牛直播SDK的Windows平台RTMP直播推送和RTMP直播播放模块为例，考虑到老的扩展CodecID 12的场景依然使用，我们添加了个设置接口：RTMP推送端，对应文件为SmartPublisherSDK 推流URL，实现Enhanced RTMP推送，播放端拉流播放，整体延迟如下：可以看到，尽管开启了Enhanced RTMP，整体延迟还在毫秒级。 技术总结鉴于目前RTMP扩展265这块，大多还是用的老的CodecID设置为12的模式，如果需要支持新的Enhanced RTMP，除了推送端和播放端外，RTMP服务端也需要做响应的调整，来适配这种情况
1.1K10编辑于 2024-03-05 - 来自专栏性能优化
RTMP协议
RTMP 基础 RTMP 概念 与 HTTP(超文本传输协议)同样是一个基于 TCP 的 Real Time Messaging Protocol（实时消息传输协议）。 当然我们也可以借助一些实现了 RTMP 协议的开源库来完成这一过程。 RTMPDump RTMPDump 是一个用来处理 RTMP 流媒体的开源工具包。 变量 file(GLOB rtmp_source *.c) # 编译静态库 add_library(rtmp STATIC ${rtmp_source} ) 在 中导入这个 CMakeLists.txt #XXX需要链接rtmp库 target_link_libraries(XXX rtmp ...) RTMP 视频数据 RTMP 视频流格式与 FLV 很相似，通过查看 FLV 的格式文档，就能够知道 RTMP 视频数据应该怎么拼接。
2.2K02发布于 2020-11-24 - 来自专栏linux驱动个人学习
RTMP协议
RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对 多向视频点播服务器直接广播到交互式会议应用程序。 RTMP协议是应用层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。 在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接。 2. 3. rtmp协议握手过程 要建立一个有效的rtmp连接，首先经过”握手”阶段，规则如下： 客户端被指定依次向服务器发送C0,C1,C2三个chunk，服务器向客户端发送S0,S1,S2三个chunk ，大小1字节 版本：8比特，C0:客户端需求的rtmp版本，S0:服务器选择的rtmp版本,如图： 4.2 握手第二阶段： 客户端发送C1包，C1包大小1536字节，格式如下图： time:包含了一个时间戳
1.5K20编辑于 2022-05-10 - 来自专栏腾讯多媒体实验室
腾讯云直播全线支持新一代视频编码标准H.266
腾讯云直播全线支持H.266 云端支持H.266，主要包括两部分：H.266的传输分发和H.266编解码的支持。 业界上行推流和低延时的场景，普遍采用RTMP协议或者HTTP传输FLV的方式；其都使用了FLV容器格式。但FLV标准已停止更新，目前缺少H.266编码格式支持。 FLV封装H.264的方式参考了MP4标准，H.264、H.265和H.266的比特流格式具有相似性，我们可以参照FLV封装H.264的方式以及MP4封装H.266的方式，来实现H.266 in FLV （腾讯云媒体处理MPS在2021 已率先在业界支持了H.266的点播功能） H.266视频编码 腾讯自研的H.266编码器O266，作为行业领先的VVC编码器，相比开源H.266编码器vvenc，在相同压缩速度下 H.266/VVC视频解码 在2020年H.266/VVC最终定稿后的三个月内，腾讯在国内率先开源发布了实时 H.266/VVC播放器O266player，内置腾讯自研的H.266/VVC解码器O266dec
2.2K20编辑于 2023-02-27 - 来自专栏RTSP/RTMP直播相关
双模式 RTMP H.265 播放器解析：从国内扩展到 Enhanced RTMP 标准的演进
一、引言：RTMP 的延续与进化在实时音视频技术的生态版图中，RTMP（Real-Time Messaging Protocol） 曾是最重要的直播协议。 作为一个 跨平台、全自研内核的音视频 SDK，它为开发者提供了完整的 RTMP 推流 SDK、轻量级 RTMP 服务端 SDK、RTMP 播放器 SDK，覆盖了从采集端 → 推流端 → 服务端 → 播放端的全链路能力 它在不破坏现有生态的前提下，增加了对 HEVC/H.265 的支持，扩展了 FLV 容器结构，使 RTMP 可以在同一链路上同时承载 H.264 与 H.265，从而为后续的 AV1/H.266 演进预留了空间 五、结语：协议规范化与工程实践的结合Enhanced RTMP HEVC 的出现，让 RTMP 在新一代音视频体系中重新焕发活力。 这意味着开发者在实际落地中能够： 无缝延续现有链路，避免被单一厂商绑定； 直接享受 H.265 带宽节省与画质升级，在 1080p/4K 场景中提升传输效率； 提前锁定演进路径，为未来向 AV1、H.266
56000编辑于 2025-08-20 - 来自专栏深度学习与python
在 AI 应用爆发前夜，H.266 成熟了
最新一代视频编码标准 H.266/VVC 正是在这种背景下，走入“舞台”中央。作为支撑庞大视频产业的核心关键要素，H.266 在流媒体生态中起着举足轻重的作用。 H.266 的重点应用场景可分为三个部分：点播、直播、RTC。虽然 H.266 硬解码器的支持正在逐步增加，但目前市场上硬解支持 H.266 的设备相对较少，尤其是一些移动终端。 因此，优化 H.266 的软件解码器就显得尤为重要。 其中，点播编解码更注重压缩效率与画质平衡，H.266 的核心优势在于压缩效率提升约 50%。 通过四叉树加多类型树（QT+MTT）分块法和色度分量双树编码，H.266 能更精细地划分编码单元，减少冗余数据。 这些特性使得 H.266 已经成为视频企业必选的技术栈、必做的标准升级。有数据显示，2026 年支持 H.266 硬解设备将超 20 亿台，推动 8K/VR 内容普及。
1K00编辑于 2025-03-03 - 来自专栏老欧说安卓
FFmpeg使用vvenc把视频转为H.266编码
前面的两篇文章分别介绍了如何在Linux环境和Windows环境给FFmpeg集成H.266的编码器vvenc，接下来利用ffmpeg把视频文件转换为VVC格式，观察新生成的vvc视频能否正常播放。 编码格式（即H.265视频编码标准）： ffmpeg -i fuzhous.mp4 -vcodec hevc ff_recode_video2.mp4 再执行下面命令，把视频文件转为vvc编码格式（即H.266 root root 278684 May 13 16:48 ff_recode_video3.mp4 由以上视频信息可见，采取H.264格式的视频大小约640K，采取H.265格式的视频大小约306K，采取H.266
75710编辑于 2025-05-22
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号